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A system and method for securely and flexibly handling prepaid card transactions in a single store, drain of stores, or multiple 
independent stores or chains of stores. Point of sale terminals are programmed to read prepaid cards and contact a host computer that 
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directly access die data base from a computer in a secure restricted manner. 
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Secure Flexible Prepaid Card System and Method 

FIELD OF THE INVENTION 

The present invention relates to prepaid card systems 
5 and, in particular, to a secure and flexible system and 
method for handling prepaid card transactions in a single 
store, chain of stores or multiple independent stores or 
chains of stores. 

10 BACKGROUND OF THE INVENTION 

Prepaid magnetic-strip cards have been used for years as 
payment for goods and services. Typically, prepaid card 
systems fall into two general classes. In one class, a value 
is stored in the magnetic strip on the back of the card and 

15 each time a card is used to purchase a good or service the 
stored value is decreased by the purchase amount. Prepaid 
cards used to pay for, for example, copies at copy machines 
typically fall into this first class. 

In the other class, a value is not stored on the card 

20 itself, but instead is stored in an account on a computer. 
The card typically contains information identifying the 
account. Prepaid phone cards are an example of this type of 
system. Prepaid debit cards offered by some department 
stores and other stores are another example . 

25 Prepaid debit card systems at department and other 

stores have typically required a major investment in hardware 
and software. For example, one known technique has been to 
implement a prepaid debit card system on top of an existing 
store credit card system. This technique involves creating a 

30 credit card account with a preloaded credit (i.e., the value 
of the prepaid debit card) and a zero dollar credit limit (so 
that the card cannot be used to charge more than the 
preloaded credit) . 

There remains a need however for a prepaid debit card 

35 system that can be implemented in stores and chains of stores 
that do not have the infrastructure to support a system in- 
house. There also remains a need for a prepaid debit card 
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system that offers multi-level security features that will 
give merchants confidence that the cards are not used in a 

fraudulent manner and a need for a system that has the 
flexibility to exploit the many advantageous uses prepaid 
5 debit cards can have in business and marketing. 

SUMMARY OF THE INVENTION 

Briefly, Che present invention provides a prepaid debit 
card system and method which is available to any merchant who 

10 has programmable point of sale terminals (such as those used 
to process credit card transactions) . The point of sale 
terminals are programmed so that they can read information 
encoded on a prepaid debit card and contact a host computer 
at a systems headquarters. The host computer processes 

15 prepaid card transactions of preferably numerous merchants 
and stores information about the transactions in a flexible, 
secure database. 

The system provides multiple levels of security to 
prevent value from being added to a prepaid card in an 

20 unauthorized manner. First, only certain terminals are 

capable of adding value to a prepaid card and those terminals 
can be kept in a secured area. Second, a list of all clerks 
who are authorized to use each terminal is stored in the 
database, further preventing a clerk from initiating an 

25 unauthorized transaction. Third, only certain terminals, 
referred to herein as manager terminals, are capable of 
adding or deleting a clerk from the list of clerks authorized 
to use a terminal. Fourth, users who access the database 
directly by connecting to the host computer from another 

30 computer, instead of from a point of sale terminal, have a 
profile stored in the database specifying whether the user 
can add value to a prepaid card account, how much the user 
can add in a single transaction, and how much the user can 
add over a specified period of time, such as a day. In 

35 addition, the host computer limits each such user's access to 
the database to information regarding specific merchants and 

- 2 - 
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the profile further specifies which portions of the 
merchants' information is accessible to the user. 

The system is also structured to exploit the use of 
prepaid cards as a business and marketing tool for merchants. 
5 For example, in a preferred embodiment of the invention, the 
database stores information necessary to implement a "buy ten 
get one free" type promotion and to implement a frequent 
buyer type promotion where cardholders are rewarded for the 
use of their prepaid cards. 
10 The present invention also provides a convenient and 

flexible mechanism for prepayment of a variety of services 
and products. One embodiment, described below, specifically 
provides a prepaid card system and method for payment of 
prepaid residential phone service. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a block diagram of the prepaid debit card 
system of a preferred embodiment of the present invention. 
Fig. 2 is a block diagram illustrating portions of the 
20 database used in an embodiment of the present invention. 
Fig. 3 is a block diagram illustrating additional 
portions of the database used in an embodiment of the present 
invention. 

Fig. 4 illustrates transaction types comprising an 
25 embodiment of the present invention. 

Fig. 5 is a flowchart illustrating an add or delete 
clerk operation initiated at a manager terminal. 

Fig. 6 is a flowchart illustrating an activation 
operation. 

30 Fig. 7 is a flowchart illustrating a redemption 

operation. 

Fig. 8 is a block diagram illustrating the services 
provided to a merchant by the host computer in a preferred 
■embodiment of the present invention. 
35 Fig. 9 is a block diagram of the services provided to a 

cardholder in a preferred embodiment of the present 
invention. 

- 3 - 
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Fig. 10 is a flowchart illustrating commission payment. 

Fig. 11 is a flowchart illustrating an activation 
operation of a prepaid residential phone card. 

Fig. 12 illustrates detail_codes for a prepaid 
5 residential phone card. 

Fig. 13 is a block diagram illustrating still additional 
portions of the database used in an embodiment of the present 
invention . 

10 DETAILED DESCRIPTION OF THE 

PREFERRED EMBODIMENTS 

Fig. 1 illustrates the basic hardware setup of a 
preferred embodiment of the present invention. In this 
embodiment, a merchant having one or more stores accepts 
15 prepaid debit cards as payment for the purchase of goods and 
services . Each store contains one or more manager terminals 
2, activation terminals 3 and/or clerk terminals 4. The 
preferred terminal is a Nurit 2080/2 085 point of sale 
terminal manufactured by Lipman Electronic Engineering Ltd. 

2 0 However, any point of sale terminal or computer device with a 

prepaid card reading capability may be used if it can be 
programmed to perform the operations described herein. 

The manager, activation and clerk terminals may be 
physically identical and their designations refer only to the 
25 functions a terminal performs. As explained below, manager 
terminal 1 can add or delete a terminal operator (also 
referred to herein as a clerk) to the system, activation 
terminal 2 can add value to a prepaid card, and clerk 
terminal 3 can redeem value from a prepaid card. Manager 

3 0 terminal 1 may also perform the functions of the activation 

and clerk terminals 3 and 4; and activation terminal 3 may 
perform the functions of clerk terminal 4 . 

Each terminal is connected, preferably by a dedicated 
phone line 5, to host computer 6 in systems headquarters 7. 
35 Host 6 processes transactions initiated by terminals 2, 3 and 
4 and updates and maintains database 8, which is on central 
server 15. Database 8, described below, contains information 

- 4 - 
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about merchants, terminals, users and transactions. Host 6 
and central server 15 are preferably Indus trial -grade Intel 
Pentium* II based computers running the Microsoft™ Windows NT 
Server operating system and the Microsoft™ SQL Server 
5 database backend program. In one embodiment of the present 
invention host computer 6 is a Compact Proliant 3000 server 
with dual Intel Pentium" II 450 MHz processors and central 
server 15 is a Compact Proliant 3000 server with a single 
Intel Pentium" II processor. Host computer 6 may be comprised 
10 of multiple computers in order to efficiently process 
numerous simultaneous calls from terminals 2, 3 and 4 in 
stores 1 . 

Host 6 is also attached to one or more workstations 9. 
Workstations 9 are used, for example, by customer service 10 

15 to access and maintain information in database 8. They may 
be any computer capable of processing web-based documents. A 
customer 11 calling customer service 10 is first connected to 
an IVR (integrated voice response) unit 12 where the 
customer's request is handled in an automated fashion, IVR 

20 unit 12 passes the call to customer service 10 if the 

automated response does not address the customer's question. 

Host 6 is also connected to merchant computer 13 via 
phone lines, Internet, local or wide area network or other 
means. This enables the merchant to request and receive 

25 reports regarding prepaid card transactions, to review and 
update database 8 , and to perform other operations . Merchant 
14 may also directly contact customer service 10, for 
example, to establish an account in the database 8. 

30 Database Overview 

Figure 2 illustrates the general structure of database 
8. Each box represents a table in the database and the 
contents of a box identify the fields of a record in the 
table. A line between two boxes indicates that the two 

35 tables have common fields, indicated by the endpoints of the 
line, over which they can be joined. As used herein, the 
tables are said to be "linked" on the common fields. The 

- 5 - 
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tables themselves are preferably stored in multiple files 
with table entries for each merchant stored in files in 
directories uniquely associated with the merchant . 

Merchants table 21 contains general information about a 
5 merchant, such as when the merchant's merchants table entry 
was created (the receipt_data field) , the types of payment it 
accepts (Visa/Master Card, American Express, prepaid cards, 
ATM cards, check verification. Diners Club, Discover, EBT 
(food stamps) , and other) (the visa, amex, prepaid_cards , 

10 atm, check_verify, diners, discover, ebt and other fields, 
respectively) , whether the merchant signed up for a payment 
and service program (the nierchant_clujb field) , whether the 
merchant's account has been cancelled (the cancelled field), 
its legal business name (the Ieg-aI_Jbusinessnaine field) , its 

15 DBA (doing business as) name (the dba field) , its tax 

identification number (the tax_id field) , the name and phone 
and fax number of a contact person (the contact, 
contact _^hone, and contact__fax fields) , its physical and 
mailing addresses (the nine fields starting with the "phys_" 

20 and "inail_" prefixes) , its field of business (the sic_code 
field) and a bank account routing number and bank account 
number (the aba and account_no fields) . It also contains a 
merchant identification number, merchant_id, which is 
assigned by the system and uniquely identifies the merchant, 

25 and a sales representative identification number (rep_id) , 
which identifies the sales representative that sold the 
merchant the prepaid card system. The rec_id field contains 
a unique number assigned to each record in the table. 

Principals table 22 contains information about the 

3 0 principals of each merchant. This information may include 
the principal's name, driver license information, phone 
number, social security number, date of birth, address, 
length of time as principal and percent ownership (the 
legalname, drivers_li cense and lic_expdate, phone, ssn, 

35 data_of_Jbirth, address, city state and zip, years, months and 
per cent_ovmer ship fields) . It is linked to the merchant 
table on the jnerchant_id field. Multiple principals table 
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entries may exist for each merchant. The principal_id field 
contains a unique number assigned to each principal. 

Rates table 24 contains information about the rates 
charged to a merchant for each of the various forms of 
5 payment accepted by the merchant. A rates table entry exists 
for each form of payment accepted by a merchant. The type of 
payment is provided in the type field. For prepaid cards, 
the merchant is charged, in one embodiment, a per item fee on 
each sale using a prepaid card, as specified in the 

10 march _jper_item field. Alternatively, a merchant may be 

charged a percentage of the sale price. Also, a merchant may 
be charged a fee for receiving a statement, as specified in 
the inercii_statement_fee field. A merchant may also receive a 
commission, specified in the merch_coOTnission field, for 

15 certain types of transactions; for example, a merchant may 
receive a commission for a sale of a prepaid card. Rates 
table 24 also stores information regarding up to three levels 
of commissions to be paid to sales representatives who were 
involved in the sale of the prepaid card system to the 

20 merchant (repl_commission, rep2_commission and 

rep3_coimiission) . These values may be used to vary the 
default commission for a representative given in reps table 
23 described below. Rates table 24 is linked to merchants 
table 21 on the merchan t_i d field. The representatives are 

25 identified through the rep_id field in the associated 

merchant table entry. The id field contains a unique number 
assigned to each record in the table. 

Reps table 23 contains information about the sales 
representatives that sold the prepaid card system to a 

30 merchant. This information may include the representative's 
name and initials (the initials, firstname, lastname, and 
minitial fields), business name {businessname field), social 
security number {ssn field) , hire and termination dates 
(Mredate and termdate fields) , address (address, city, state 

35 and zip fields) , phone, fax and email information {phone, fax 
and email fields) , default commission rate (defaultcomm 
field) and a flag indicating whether a commission report is 

- 7 - 
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sent to the representative (report field) . A reps table 23 
entry is linked to the merchants table on the rep_id field. 
An entry in the reps table may also be linked, on the iso_id 
field, to another reps table entry, thus identifying a sub- 
5 representative. In the preferred embodiment, two sub- 
representatives may be entered for each representative, for a 
total of three representative and sub-representatives. The 
three correspond to the three levels of commissions in rates 
table 24 . Any number of representatives and svib- 

10 representatives may be allowed in alternative implementations 
of the present invention. Each record in reps table 23 is 
also linked on the type field to the type_id field' in 
rep_type table 25 , Rep_type table 25 identifies the type of 
sales representative (internal or external) in its 

15 description field. 

Terminals table 2 6 contains information about each 
iierminal owned by each merchant. Multiple records in 
terminals table 26 may be associated with a single merchants 
table entry. The merchant_id field identifies the store 

20 where the terminal is located and provides a link to the 
store's entry in merchants table 21. The owner_id field 
identifies the owner of the store if, for example, the store 
is part of a chain. The millenniujn_no field contains an 
identification number assigned to each terminal by the 

25 system. The manager_card field contains the manager card 
number for the terminal. A terminals table record is linked 
on the raillennimn_no field to possibly multiple records in 
terminal_^as swords table 27. Other information about each 
terminal may include identification numbers of various 

30 debit /ATM and credit card processors (the Iyn;c_no, gen3ar_no, 
visanet_no, buypass_no, and inelion_no fields) , serial numbers 
and manufacturer/model information for the terminal, its 
pinpad and its printer (the serial_no, pinpad_sernmn, 
printer_sernum, terminal_type, pinpad_type and printer_t3^e 

35 fields) , the date the terminal was shipped to the customer 
{shipjdate field), the version number of the terminal's 
software (version field) , a flag indicating whether use of 
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the terminal is password protected {i.e., limited to certain 
clerks as described below) (password field) , and whether a 
terminal is, e.g., leased or purchased (purciiase_type field). 
The rec_ld field contains a unique number assigned to each 
5 record in the table. 

Terminal jpas swords table 27 contains the passwords (or 
clerk numbers) of the clerks who are authorized to use the 
terminal identified in the miIlenniujn_no field. The password 
field contains the password or clerk number. Multiple 

10 terminal_passwords table entries may exist for each terminals 
table entry. The rec_id field contains a unique number 
assigned to each record in the table. 

Figure 3 illustrates other tables in database 8. Cards 
table 41 contains an entry for each prepaid card that is 

15 distributed to a merchant. The Pin field contains a unique 
identifier for each prepaid debit card. This identifier is 
also encoded in the magnetic strip on the back of the card 
(or printed on or otherwise associated with a card) . The 
Product_id field links the entry to an entry in Products 

2 0 table 42, which identifies the type and characteristics of 
the prepaid card. The Control_no, Batch, and Lot fields 
provide tracking information for each card. The Disabled 
field indicates whether the card has been disabled. The 
Balance field specifies the current cash balance available on 

25 the prepaid card. Other fields in Cards table 41 are 
discussed below. 

Products table 42 contains information about groups of 
cards. The Id field contains a product identification 
number. The Description field identifies the type of the 

30 cards in the group (e.g., prepaid debit card, prepaid phone 
card, etc.). The Disabled field indicates whether all the 
cards in the product are disabled. The Pin_count field 
contains the number of cards in the group and the 
Activation_count contains the number of cards that have been 

35 activated. The {7sage_ajnount field contains the total amount 
debited from all the cards in the group and the 
Activation_aiT!ount contains the total amount of value added to 
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the cards in the group. The Prompt field indicates the 
language that prompts from the host computer should be in. 
The Expirejdate field contains the date on which all cards in 
the group expire. The Program_id field identifies the 

5 software program that is associated with the cards in the 
group; for example, one program may be run for a specific 
group of prepaid debit cards and a different program may be 
run for a different group of cards. Finally, the 
Rechargeable field indicates whether the cards in the group 
10 may be recharged (i.e., whether value may be added to a 
card) . 

Transactions table 43 contains information about all 
transactions processed by the system. The rec_id field is a 
unique identification number assigned to each record in the 

15 table. The Datetime field specifies the date and time of a 
transaction. The Pin field specifies the pin number of the 
prepaid card used in the transaction and provides a link to 
the entry for that card in cards table 41. The Type field 
specifies the type of the transaction. These types include 

20 (1) original activation, (2) recharge, (3) return, (4) CS 
(customer service) credit, (5) test transaction, and (6) 
redemption, as shown in Figure 4. The test transaction type 
is used to test the system. The other types of transactions 
are described below. The Account_id field specifies the 

25 terminal number of the terminal on which the transaction was 
performed and provides a link to the entry for that terminal 
in terminals table 26 -- Account_id in transactions table 43 
has the same meaning as iT]iIle2inium_no in terminals table 26. 
The Amount field contains the amount of the transaction, if 

30 applicable. The Clerk field contains the password (or clerk 
number) of the clerk (or other user) that handled the 
transaction; it has the same meaning as the password field in 
terminal_passwords table 27. The Ach_flag and Ach_datetime 
fields indicate whether the system has processed the 

35 transaction against the merchant's account and, if so, when. 
The Client and Port fields indicate the host computer that 
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processed the transaction, if there is more than one host, 
and the port number on the host computer that was used. 

A person skilled in the art will recognize that there 
are many different ways of configuring the tables in database 
5 8, and the present invention is not limited to the 

configuration shown herein. Different and/or additional 
tables may be used and different and/or additional fields may 
be used in the tables. 

Additionally, tables and fields may be added to database 

10 8 to support, for example, a prepaid phone card system. In 
this case, rates table 24 could, for example, contain rate 
and commiB sion information regarding phone card plans, cards 
table 41 and products table 42 could contain rateplan 
information, and additional tables could be added that stored 

15 inbound and outbound call information for each card and call 
routing and language information for each prepaid phone card 
product . 

Manager Terminal 

2 0 Manager terminals are, in one embodiment of the present 

invention, the only terminals at which clerks or other 
terminal operators can be added or deleted from database 8. 
For added security, the add/delete function can only be 
activated after a valid manager card is swiped through the 

25 terminal. Manager cards are provided by Lipman Electronic 
Engineering, Ltd. for each Nurit terminal to enable 
restricted access to special terminal features that may be r 
defined by purchasers of the terminals. The add/delete clerk 
function is not a feature of the standard Nurit terminal. 

30 The add/delete clerk function is illustrated in Figure ' 

5. In step 70, a manager or authorized clerk swipes a 
manager card through the manager terminal. In step 72, the 
manager then selects an add or delete clerk operation on the 
terminal . In step 74 , the manager enters a clerk number (or 

35 password) . In step 76, the terminal then calls host 6 in 
systems headquarters 7 and sends it a message containing a 
transaction code specifying either an add clerk or delete 
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clerk transaction, the terminal's identification number, the 
clerk number, and manager card identification information. 

In step 78, host 6 examines terminals table 26 in 
database 8 and determines whether the received terminal 
5 number is valid -- i.e., whether an entry exists for it in 
the database. If it is valid, then host 6, in step 80, tests 
whether a valid manager card was used. If the manager card 
is valid, step 86 is executed. Otherwise, if either the 
terminal number or manager card is invalid, step 82 is 

10 performed in which host 6 sends a message to the terminal 
indicating that the transaction is not authorized. 

In step 86, the received clerk number is added or 
deleted, depending on the transaction code, to or from the 
database. For an add clerk transaction, a terminal_pas swords 

15 entry is created, with the password being the received clerk 
number (or password) , for each terminal in the same store as 
the calling terminal (i.e., each terminal whose terminals 
table entry has the same inerchant_id as the calling 
terminal) . For a delete clerk transaction, every entry in 

20 terminal_passwords table 27 whose millenniimi_no identifies a 
terminal in the same store as the calling terminal and whose 
password is the same as the received clerk number (or 
password) is deleted. 

In alternate embodiments, different or additional 

25 information may be transmitted from the terminal to host 6. 
For example, the manager or authorized clerk may also specify 
a specific terminal number or set of terminal numbers that a 
clerk is to be added to or deleted from. Also, a software 
version number may be transmitted so that the host can check 

30 it against the version field of the calling terminal's entry 
in terminals table 26, as an added verification of the 
calling terminal. 

Prepaid Debit Card 
35 In one embodiment of the invention, each prepaid debit 

card has a magnetic strip on the back having data in the 
following format: 
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account number, field sep, yymm, use code, filler 

where account number is preferably a long random number 
assigned to the card; field sep is a field separator, such as 
5 ' = ', yyrnn is the year and month the card expires; use code is 
the American Bankers Association code specifying where 
geographically the card can be used (a use code of 101 means 
the card can be used anywhere) ,- and filler is filler for 
possible future use. 

10 An entry in cards table 41, described above, is created 

for each card that is manufactured and shipped to a merchant. 
Preferably, a card is initially given a balance of $0 (i.e., 
the Balance field of its Cards table entry is set to 0) , 
though a merchant may request that the accounts be preloaded 

15 with some value for, for example, a promotion. 

Activation Terminal 
Activation terminals 3 (and manager terminals 2) contain 
software that enable value to be added to a prepaid card. 
20 Clerk terminals 4 do not contain this software and therefore 
a clerk without access to an activation or manager terminal 
cannot perform this function. 

Figure 6 is a flowchart illustrating the process of 
adding value to a prepaid card from an activation terminal. 
25 In step 90, a clerk swipes a customer's prepaid debit card in 
an activation (or manager) terminal. The terminal then 
prompts the clerk for the type of transaction and in step 92 
the clerk selects an activate (add value) transaction. The 
clerk then enters the amount to be added to the prepaid card 
30 and his or her clerk number in steps 94 and 96. 

In step 98, the terminal connects to host 6 via, in one 
embodiment, an asynchronous modem connection, and transmits a 
message having the following format: 

35 <stx>,MBSSAG£<etx><lrc> 
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where <stx> is a start of text indicator, <etx> is an end of 
text indicator and <lrc> is linear redundancy check, which is 
calculated from the body of the message and used as a simple 
error correcting mechanism. If the <lrc> calculated by the 
5 host does not equal the <lrc> sent by the terminal, the host 
sends a <nak> (negative acknowledge) character to the 
terminal and the terminal will resend the message. This is 
repeated up to three times before the host sends an <eot> 
{end of transmission) character and disconnects the phone 
10 line. 

If the <lrc> calculated by the host matches the one sent 
by the terminal, the host processes the body of the message, 
MESSAGE. The MESSAGE sent by the terminal has the following 
comma delimited fields : 

15 

[transaction type] , [terminal number] , 

[pin number] , [amount] , [clerk number] 

where transaction type is the type of the transaction, in 

2Q this case an activate transaction, terminal number is the 
terminal number of the calling terminal, pin number is the 
account number encoded on the swiped prepaid card, amount is 
the amount to be added to the account associated with the 
swiped prepaid card, and clerk number identifies the clerk. 

25 In step 100, host 6 determines the type of transaction 

from the transaction t_ype field of the received message. If 
it is an activation, the host then performs step 102 in which 
it determines whether the received terminal number is valid 
(whether it, for example, has a valid entry in terminal© 

2Q table; 2i®Jsii; If it is valid, the host determines, in step 103^ 
whether the clerk is authorized to use the terminal. This is 
done by searching the terminal_pas swords table 27 for an 
entry having inilIeniiiiun_no set to the received terminal 
number and password set to the received clerk number. If the 

25 clerk is authorized to use the terminal, the host then 
determines, in step 106, whether an entry exists in cards 
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table 41 for a card with the received account number. If it 
does then processing proceeds to step 108. 

If the results of any of the tests in steps 102, 103 or 
106 are negative (i.e., the terminal is invalid, the clerk is 
5 not authorized to use the terminal, or the received prepaid 
card account number is invalid) , step 104 is performed in 
which the host sends a message to the terminal indicating 
that the requested transaction has been denied. 

Otherwise, in step 108 the host calculates the new 

10 balance for the card by adding together the current balance 
for the prepaid card from the Balance field in the card's 
cards table entry and the received activation amount. It 
then sends a message to the terminal stating that the 
requested transaction is authorized (i.e., "OK") and what the 

15 new card balance is. The message is in the same message 

format as the one earlier sent from the terminal to the host 
-- <stx>,MBS£>AGB<etx><lrc> . The terminal performs an <lrc> 
check on the message and, if the message is valid, the 
terminal sends an <ack> (positive acknowledge) character to 

20 the host. Otherwise, the terminal sends a <nack> character 
to the host, and the host attempts to resend the message. If 
the host fails after three attempts, it sends an <eot> 
character and disconnects the phone line in step 112 . 

In step 110, the host tests whether it received an <ack> 

25 character back from the terminal. If it did, it hangs up the 
call in step 114 and updates the cards table entry for the 
received card number with the new balance . The host also 
creates an entry in transactions table 43. If this was the 
first time value was added to the card, the transaction type 

30 is set to indicate an original activation; otherwise, the 
transaction type is set to indicate a recharge. 

If the host did not receive an <ack> character, but 
instead received a <nack> character, two more attempts are 
made to send the message from the host to the terminal and if 

35 those fail too, the host hangs up in step 112 and does not 
update the cards table. 
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Clerk Terminal 
Clerk terminals 4 (as well as activation and manager 
terminals 2 and 3) contain software for redeeming value from 
a prepaid debit card and returning a prepaid debit card. A 
5 redemption is performed, for example, when the card is used 
to purchase goods or services . 

Figure 7 illustrates the process of redeeming value from 
a prepaid card. The first six steps in the process are 
similar to those for the activation process described above. 

10 The clerk swipes a customer's prepaid card in a terminal in 
step 130, and selects a redeem operation at his or her 
terminal in step 132 , The clerk 'then enters the amount to be 
redeemed in step 134 and his or her clerk number in step 136. 
The terminal then connects, via, for example, a dial-up 

15 connection, to host 6 in step 138, and sends a message having 
the same format as that for an activation except that the 
transaction type field specifies an redemption transaction. 

In step 14 0, the host determines the type of the 
transaction and, if the transaction is a redemption, performs 

20 step 142. In step 142, the host determines if the call is 
from a valid terminal, for exanple, by checking whether a 
terminals table entry exists for the received terminal 
number. If the terminal is invalid, the host sends, in step 
144, a message to the terminal indicating that it is invalid 

25 and hangs up (step 162) . If the terminal is valid, the host 
next determines, in step 148, whether the clerk is authorized 
to use the terminal. Again, this is done by checking if 
there is a terminal_passwords table entry in which the 
7iiiIlennium_no field is set to the received terminal number 

30 and the passwords field is set to the received clerk number. 
If the clerk is authorized to use the terminal, the host then 
determines, in step 150, whether the prepaid debit card 
exists in database 8 by searching Cards table 41 for an entry 
whose Pin field is the same as the received card accovmt 

35 number. If the card exists, and is not disabled, then step 
154 is executed. If steps 148 or 150 determine that the 
clerk is not authorized to use the terminal or the prepaid 
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card is not valid, the host sends, in step 152, a message to 
the terminal that the transaction is declined and hangs up 
(step 162) . 

In step 154, the host compares the received redemption 
5 amount to the current balance stored in the cards table entry 
for the card to determine if there is sufficient funds. If 
there is not sufficient funds, the host sends a message to 
the terminal indicating the current balance and that there is 
not sufficient funds for the transaction (step 156) and 

10 terminates the phone connection (step 162) . If there is 
sufficient funds, the host sends a message to the terminal 
indicating the available balance left after the transaction 
and that the transaction is approved (step 158) . The host 
then waits for a positive acknowledgement from the terminal 

15 (step 160) and if it does not receive one after three 

attempts to transmit the message to the terminal, it hangs up 
(step 162) . 

If the host receives a positive acknowledgement it then 
updates the cards table entry for the received account number 

20 by debiting the received redeinption amount from the balance 
field and adding the redemption amount to the totaI_usage 
field (step 164) . The host also creates, in step 164, a 
transactions table entry, setting the Pin field to the 
received account number, the Type field to indicate a 

25 redemption, the Account_id field to the received terminal 

number, the Amount field to the amount of the redemption, the 
Clerk field to the received clerk number, and the Ach_flag 
field to 0, indicating that commissions on the redemption 
have not yet been processed. The host then hangs up in step 

30 152. 

The process for a card return is similar to the 
processes described above. The clerk swipes the card, 
presses the appropriate keys on the terminal for a return 
transaction and enters his clerk number. The terminal then 
35 calls the host computer, which verifies that the calling 
terminal is valid, that the clerk is authorized to use the 
terminal and that the card is valid. The host then sends a 
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message to the terminal indicating the remaining card balance 
and, waits for a positive acknowledgement from the teiminal. 
If it receives it, the host updates the cards table entry for 
the prepaid card, setting the balance to zero. It also 
5 creates a transaction table entry, setting the transaction 
type field to indicate a return. 

All terminals also have software for producing batch 
reports that itemize and total all transactions performed at 
a terminal over a period of time. 

10 

Commission Payment 
Transactions table 43 is periodically scanned by host 
computer 6, preferably once a day, in order to collect 
commissions from the merchants for prepaid card transactions. 
15 A flowchart of this process is illustrated in Figure 10. 

In step 250, the host computer sets the current entry to 
the first entry in the transactions table. Step 2 52 
determines whether the transaction is a redemption by 
examining the entry's type field. If it is, step 254 is 
20 performed which determines whether the transaction has 

already been processed by examining the ach_flag field. If 
either the transaction is not a redemption or the transaction 
has already been processed, then processing continues at step 
262. 

25 Otherwise, step 256 is performed, in which the host 

computer determines the amount of commission owed by the 
merchant . This involves finding the rates table entry 
associated with the transaction by tracing the links from 
transactions table 43 to terminals table 26, then from 

30 terminals table 26 to merchants table 21, and from merchants 
table 21 to rates table 24. In step 258, the commission is 
withdrawn from the merchant's bank account using the routing 
code found in the ajba_no field of the corresponding terminals 
table entry. 

35 In step 260, commissions owed to sales representatives 

and sub-representatives are calculated using the information 
in the corresponding rates table entry found above and the 
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corresponding reps table entry, which is found by following 
the link from the corresponding merchants table entry to reps 
table 23. 

In step 262, the current entry is set to the next 
5 transactions table entry. Step 264 tests if the end of the 
table has been reached. If it has, the process is over (step 
266); otherwise the process returns to step 252. 

Merchant Services 

10 In a preferred embodiment of the invention, a merchant 

is provided direct access to the information stored in 
database 8, as illustrated in Figure 8. 

In step 180, a user at, for example, merchant computer 
13 (in Figure 1) connects to host computer 6 via, e.g., a 

15 dial-up connection, a hardwired connection or the Internet. 
For each user who may access host computer 6 in this manner, 
a users table entry must first be created. 

Users table 28 is shown in Figure 2. The initials field 
contains the user's initials. The fullname field contains 

20 the user's full name. The password field contains a password 
for the user. The last_login field contains the date and 
time the user last used the system. The credit field 
specifies whether the user is authorized to issue credit 
(i.e., add value) to a prepaid card. The credit field 

25 specifies whether a user can issue a credit. The creditlimit 
field specifies the maximum amount of credit the user is 
authorized to issue per transaction. For example, a user may 
be authorized to credit no more than $5 at a time. The 
dailylimit field specifies the maximum amount the user is 

30 authorized to issue per day. The reps, merchants, and comms 
fields specify whether the user is authorized to access the 
reps, merchants and rates tables, respectively. The users_id 
field contains a unique number assigned to each record in the 
table . 

35 In step 182, host computer 6 verifies the user's access 

rights by, for example, prompting the user for his or her 
initials and passwords, looking up the users table entry for 
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the user having the entered initials and comparing the 
entered password to the password field of that users table 
entry. Alternatively, a user's access rights may be verified 
based on the phone number the user is calling from -- using 
5 ANI (automatic number verification) or Caller ID to identify 
the originating phone number --or the Internet IP address of 
the user, if the user is accessing the host via the Internet. 
Other verification techniques may also be used. 

In a preferred embodiment of the invention, operating 

10 system features on the host computer are used to limit a 
user's access to the database, permitting a user to access 
only the data of a specific merchant or group of merchants. 
For example, in Windows NT, a user's profile maintained by 
the operating system can be used to limit access by the user 

15 to files only in specified directories. Accordingly, on a 
Windows NT system, the tables in database 8 can be stored in 
multiple files, with each file containing data regarding one 
merchant and stored in a directory that only contains files 
regarding that merchant. A user's access to information 

20 about specific merchants can then be implemented using the 
directory restriction feature. 

Returning to Figure 8, if access is denied in step 182, 
the connection is terminated in step 184. Otherwise, the 
user may choose either to access the raw data for the 

25 merchant directly (step 186) or to access the data through a 
browser-based interface 188 on the host computer. The former 
option would typically be chosen by users who have their own 
software for querying the data and generating reports. In 
either case, merchants are provided with real-time 

30 information about all transactions processed by host computer 
6. 

Interface 188 provides at least the following features: 
form queries 190, report generator 192 and card specific 
functions 194. 

35 Form queries 190 are forms which a user fills in to 

perform various queries on database 8 . 
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Report generator 192 generates daily reports 196, weekly 
reports 198 and monthly reports 200, which itemize and/or 
summarize prepaid card transactions for the merchant over the 
relevant time period. Reports may present information on a 
5 per terminal or per card basis, if desired. Also, reports 
may be sent to the merchant on a periodic basis by, for 
example, fax or mail. Reports for chains of stores, for 
example in a franchise, may be consolidated so that 
activations and redemptions among the various stores in the 

10 chain may be reconciled. For example, if over the relevant 
time period store A in a chain activated a card for $10 and 
did not redeem value from a card and stored B redeemed $5 but 
did not receive any money to activate a card, then $5 should 
be transferred from store A to store B, since store B gave 

15 the cardholder $5 worth of goods or services, but did not yet 
receive any payment for it . 

Card specific functions 194 allow a merchant to directly 
service customers, if desired. Merchants may prefer however 
to have customers use customer service 10 in systems 

20 headquarters 7, as described below. Card-specific functions 
include looking up a balance on a prepaid card 202, issuing 
credit 204, and adding to, or otherwise accessing, 
information in a notes table, which is a log of cardholder 
requests and complaints. 

25 As a security feature, a user's ability to issue credit 

is limited by the information in the user's user table entry. 
As explained above, the user table entry specifies whether a 
user may issue credit (the credit field) , the amount of 
credit that may be issued in a single transaction (the 

30 creditlimit field) and the amount of credit that may be issue 
in a single day (the dailylimit field) . A credit issued 
through interface 188 (or customer service 10) generates a 
transactions table entry with the transactions type 
preferably set to indicate a CS (customer service) credit. A 

35 credit is also reflected in the cards table entry for the 

prepaid card, with the Balance and rotal_credits fields being 
incremented by the credited amount. 
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Also, a user's ability to access the reps table, 
merchants table, rates table is restricted based on the 
contents of the reps, merchants and comms fields. 

5 Cardholder Customer Service 

A cardholder who has questions about his or her prepaid 
card may call customer service, as illustrated in Figure 9. 
In step 220, a cardholder calls customer service and is 
connected to an IVR (integrated voice response) unit in step 

10 222 . The IVR unit handles certain requests in an automated 
fashion, such as a request to get the balance on a prepaid 
card 224 or to find the closest location accepting the 
cardholder's card 226. To get the balance, the IVR unit 
prompts the cardholder to enter the account number of the 

15 card and then looks the information up in cards table 41. To 
get the closest location, the IVR unit preferably determines 
the cardholder's current location based on the originating 
telephone number, which is determined using for example ANI 
or Caller ID. 

20 If the cardholder desires other services, the call is 

connected to a customer service representative 228. The 
customer service representative can for example provide 
information on past transactions 230, issue credits (if 
authorized to do so) 232, and add notes to the notes table 

25 234 . Each customer service representative has an entry in 
users table 28 and is provided access to database B in the 
same manner as other users. A customer service 
representative may have authorization to examine the data of 
multiple merchants. 

30 

Card Uses 

The prepaid card system of the present invention 
provides the flexibility to irrplement many special features. 
For example, a "buy 10 get 1 free" type promotion can be 
35 implemented by adding a niun_tijiies_used field to cards table 
41, which contains the number of times a card has been used 
for a redemption. When a card is used for a transaction, the 
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host computer can then include in a message to the terminal 
that the cardholder is, for example, enti-tled to one free 
product if the card was previously used ten times, two free 
products if the card was previously used twenty times, etc. 
5 If the cardholder chooses to accept a free product, the 
nui7i_tii7ies_used field is decremented by ten. Of course, any 
number of previous uses may be used and any bonus or prize 
may be substituted for a free product. For example, a 
cardholder may be given discounted products instead of free 
10 products or the cardholder may have value added to his or her 
card. 

Similarly, a frequent user rewards program, in which a 
cardholder earns points towards free or discounted products 
or other prizes, can be implemented by adding a 

15 redeemed _j)oints field to cards table 41. For example, each 
dollar spent may be considered a point toward a bonus or 
prize. The Totaljasage field in cards table 41 then 
corresponds to the total number of points a cardholder has 
earned and the redeemed jpoints field would contain the total 

20 number of points a cardholder has already cashed in. The 
Total_u3age minus the redeejned_j3oii2ts in this example gives 
the currently available points. 

The prepaid cards may also be conveniently used to serve 
various business functions. For example, a prepaid card may 

25 be used as a store credit voucher for returned items, instead 
of the slips of paper that are now typically used. They may 
also be used as a store credit voucher even without a return, 
for example, as a grand opening promotion or other promotion. 
The prepaid card system of the present invention is not 

30 limited to the uses and the specific implementations 
described above. 

Prepaid Residential Phone Cards 
An embodiment of the present invention for paying for 
35 prepaid local phone service is illustrated in Figures 11 
through 13. 
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Prepaid local phone services are used by customers who, 
because of credit problems or other reasons, do not qualify 
for regular phone service in which bills are sent typically 
monthly. In known such services, the customer must go each 
5 month to a vendor associated with the service provider and 
prepay the bill for the following month. For an initial 
activation of the service, the vendor must get required 
information from the customer, such as the customer's name, 
address and types of services desired (e.g., call waiting, 

10 caller ID, call forwarding, etc.) and communicate this 

information to the service provider. Each subsequent month, 
when the customer prepays for the next month, the vendor must 
communicate payment information, as well as any changes in 
requested services, to the service provider. This process is 

15 burdensome to some vendors. 

This embodiment of the present invention simplifies and 
automates the above process. Briefly, for an initial 
activation, the vendor provides the customer with a prepaid 
card, as described above, swipes the card in a terminal and 

2 0 enters the amount of money provided by the customer, 

information regarding the desired services and the vendor's 
clerk number. The terminal then calls the host computer, 
which verifies the clerk number and that the received amount 
is sufficient. The customer later directly calls the service 

25 provider (e.g., using a service provider's toll free number), 
provides the account number on the prepaid card and provides 
the required account set-up information. For subsequent 
payments, the vendor swipes the customer's card at the 
terminal (or enters the customer's phone number if the 

30 customer does not have the card) and enters the amount of 
money provided by the customer, information regarding the 
desired services and the vendor's clerk number. The terminal 
again calls the host computer, which again verifies the clerk 
number and that the amount of money provided is sufficient. 

35 Figure 11 illustrates the activation process for this 

embodiment (i.e., adding value to a prepaid card account) in 
more detail. In step 300, the vendor swipes a customer's 
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prepaid card or enters the customer's home phone number. The 
vendor then selects an activate transaction (step 302) and 
enters the amount of money provided by the customer (step 
304) and the vendor's clerk number (step 306). Next, the 
5 vendor enters a product code, indicating the services the 
customer wants to purchase (step 308) . In one embodiment 
this code is a sequence of two digit numbers, each number 
indicating a service. Examples of product codes for a 
prepaid residential phone card are shown in Figure 12. 
10 In step 310, the terminal connects to host 6 via, in one 

embodiment, an asynchronous modem connection, and transmits a 
message having a format similar to that described above in 
connection with Figure 6 except that the clerk number field 
is divided into two fields, as follows: 

15 

[clerk nTomber] | [product code] 

where clerk number identifies the clerk and product code is 
the entered product code . The host computer then processes 

20 the received message as in Figure 6, first determining 

whether the transaction type is an activation (step 312) and 
then determining whether the call is from a valid terminal 
(step 314) , whether the clerk is authorized to use the 
terminal (step 316) and whether the prepaid card used in the 

25 transaction has an entry in cards table 41 (step 318) . In 
this embodiment, cards table 41 will also contain a phone 
field, identifying the phone number associated with the card, 
if one has been assigned, so that cards table 41 can" be 
searched both on a received card pin number or a received 

30 phone number. If the terminal is not valid, the clerk is not 
authorized or the card is not in the database, the host sends 
a message to the terminal indicating that the requested 
transaction is denied (step 330) and hangs up (step 322) - 
Otherwise, step 324 is performed. 

35 In step 324, the host computer determines the price of 

services specified in the product code. First, the product 
table entry associated with the card is found via the link 
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between the product_id field of the cards table entry and the 
id field of an entry in products table 42." Next, for each 
two-digit subcode in the received product code, the host 
locates an associated product_details table entry. The 
5 format of product_details table 372 is shown in Figure 13 . 
The rec_id field is a unique identifier for each record in 
the table. The detail_code field is a code identifying a 
service/product, such as those shown in Figure 12. The 
amount field specifies the price of the service. The 

10 description field provides a description of the service. The 
product_id field provides a link to the id field of an entry 
in products table 42 (shown in Fig. 2) . A products table 
entry may be linked to multiple product_details table 
entries . The host computer then sums the price of each 

15 service/product specified in the received product code. 

In step 326, the host computer determines if the card's 
balance specified in the balance field of the located cards 
table entry plus the received amount is sufficient to pay for 
the services/products specified in the received product code. 

2 0 If it is not, the host sends a message to the terminal 

indicating that there is not sufficient funds and specifying 
the amount required for the requested transaction (step 328) 
and hangs up (step 320) . Otherwise, the host sets the 
balance field of the cards table entry to the new balance and 

25 sends a message to the terminal stating that the transaction 
is authorized and what the new card balance is (step 332) . 
The host then checks if the terminal positively acknowledges 
receipt of the message (step 334) . 

If a positive acknowledgment is received, the host 

30 computer hangs up (step 336) and, in step 338, updates the 
cards table entry with the new balance and creates a 
transactions table entry. In this embodiment, each 
transaction table entry is linked to possibly multiple 
transact ion_details table entries, which are also created at 

35 this time. The format of transaction_details table 370 is 
shown in Fig. 13. The rec_id field is a unique 
identification number assigned to each entry in the table. 
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The transact ion_id field links the entry to an entry in 
transactions table 43. The prBduct_detail_id field links the 
entry to an entry in product_detailB table 372. The 
Export_Status field, as explained below, is set to 0 before 
5 the transaction has been posted for retrieval by the phone 
provider and 1 after the transaction has been posted. The 
Acknowldege_Date field indicates the date the phone provider 
has processed the transaction. For overcharge transactions 
received from the phone provider, which are described below, 
10 the amount field is set to the amount of the overcharge and 
the Acknowledge_Date is set to 3 after the transaction is 
processed. 

If a positive acknowledgment was not received after 
three attempts, the host hangs up and does not update the 

15 database, (step 322) . 

Periodically, preferably every minute, host computer 5 
scans transaction table 43 for transactions involving 
residential phone cards. For each such transaction, the host 
computer posts the transaction information and the balance on 

2 0 the associated card and then sets the card's balance to zero 
and changes the Export_Status field of the associated 
tjransaction_detaiIs entries from 0 to 1. The information is 
posted such that the prepaid residential phone provider can 
retrieve it using, for example, a computer via an Internet or 

25 other connection. The residential phone provider then 

processes the transaction and contacts, again for example via 
a computer connection, the host computer which in turn sets 
the AcJcnoh^ledge_L)ate field in the transaction_details entry 
for the transaction. Also, if the customer's balance 

30 exceeded the amount needed for the transaction, the provider 
sends overpayment information to the host computer and the 
host computer creates a transactions table entry, and an 
associated transaction_details entry, for the customer. In 
this case, the product_detail_id field of the 

35 tran3action_details entry is linked to a product_details 
table entry for an Overpayment. The amount of the 
overpayment is stored in the amount field of the 
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transa.ction_deta.il s table. When the host computer 
periodically scans the transactions table, it processes 
overpayment transactions by crediting the customer's card 
balance and setting the Export_Status field of the associated 
5 transaction_details table entry to 2. 

For an initial activation transaction, the customer, 
after prepaying for the service at a vendor and receiving his 
or her residential phone card, calls the phone provider (from 
a payphone or other phone) and provides the card number and 

10 certain required information, such as his or her address. 
The provider then contacts host computer 6 using any of the 
techniques discussed above (for example, through customer 
service 10, using its own computer to directly connect to 
host 6, or using a terminal) and provides the customer's card 

15 number. The host computer then verifies that there is an 
initial activation transaction associated with the card 
number in the transactions table and that the card has a 
balance. If both items are verified, the host computer 
reports the available balance and the services/products sold 

20 to the customer. It then sets the Acknowledge_Date field in 
the associated transaction_detail table entries. If both 
items are not verified, the host computer reports that the 
card is not found or that it has no balance. 

25 In this disclosure, there is shown and described only 

the preferred embodiments of the invention. It is to be 
understood that the invention is not limited to the 
particulars disclosed and extends to all equivalents included 
within the scope of the claims. For example, although 

30 particular data structures and algorithms were shown and 
described, other data structures and algorithms may 
equivalently be used. Moreover, the invention is not limited 
to particular types of hardware (computers, electronic 
device, etc.). For example, manager, activation and clerk 

35 terminals may be any electronic or microprocessor-based 
device that performs the required functions; connections 
between devices, such as the terminals and host computer, may 
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be any type of connection that permit the devices to 
communicate be it by telephone lines, wireless 
communications, local or wide area networks, or otherwise; 
and any device shown as a single unit may be implemented as 
5 multiple units (for example, multiple computers may comprise 
host computer 6) and multiple units may be combined into a 
single unit . 
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What is claimed is : 



1. A prepaid card system comprising: 

a. one or more prepaid cards each having an associated 

5 account number; 

b. at least one activation terminal at which value can 
be added to the one or more prepaid cards; 

c. at least one clerk terminal at which value can be 
redeemed from, but not added to, the one or more 

10 prepaid cards; 

d. a host computer connected to the at least one 
activation terminal and the at least one clerk 
terminal ; and 

e. a database that can be accessed by the host 
15 computer wherein the database stores 

i) for each of the at least one activation and 
clerk terminals, information regarding each 
clerk authorized to use the terminal; and 

ii) for each of the one or more prepaid cards, a 
20 current balance associated with the prepaid 

card. 



2 . The system of claim 1 further comprising at least one 
manager terminal wherein: 
25 a. the database further stores, for each of the 

manager terminals, information regarding each clerk 
authorized to use the manager terminal; and wherein 
b. the information regarding each clerk authorized to 
use each of the activation, clerk and manager 
30 terminals can be modified from the manager 

terminal . 



3 . The system of claim 1 further comprising a second 

computer connected to the host computer wherein the 
35 database further stores information regarding access 

rights of users of the second computer to information in 
the database, including, for each user, 
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a. whether the user may increase the current balance 
associated with each of the one or more prepaid 
cards ; 

b. an amount the user may add to the current balance 
associated with at least one of the one or more 
prepaid cards in a single transaction; and 

c. a total amount the user may add to the current 
balance associated with at least one of the one or 
more prepaid cards over a specified period of time. 

The system of claim 1 wherein the database further 
stores for each terminal information regarding a 
merchant that owns the terminal . 

The system of claim 4 wherein at least two terminals in 
the database are owned by different merchants. 

The system of claim 1 wherein the database further 
stores transaction information regarding each 
modification to the current balance associated with at 
least one of the one or more prepaid cards, the 
transaction information comprising: 

a. an identification of the terminal at which the 
transaction was initiated, 

b. an identification of the clerk who initiated the 
transaction; 

c. an identification of the prepaid card whose current 
balance was modified; 

d. an amount of the transaction; and 

e. a type of the transaction. 

The system of claim 6 wherein the database further 
stores merchant information comprising: 

a. a list of terminals associated with a merchant; 

b. a list of sales representatives entitled to 
commissions for transactions occurring at terminals 
associated with the merchant, 
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c. information regarding commissions owed to the sales 
representatives on the list of sales 
representatives and a commission owed to an 
operator of the host computer, and 
5 d. information identifying a bank account number from 

which commissions are to be paid. 

8 . The system of claim 7 wherein the transaction 
information further comprises, for each transaction for 

10 which a commission is owed, information regarding 

whether the commission has been paid from the merchant's 
bank account. 

9. The system of claim 5 wherein the database is structured 
15 such that information relating to a first merchant is 

stored in a different directory from information 
relating to a second merchant. 

10. The system of claim 9 wherein a user at a merchant 
20 computer can be connected to the host computer, and 

wherein the host computer limits the user's access to 
the database to information regarding one or more 
specific merchants. 

25 11. The system of claim 10 wherein the merchant computer 
connects to the host computer via the Internet. 

12 . The system of claim 1 wherein the database further 
stores, for each of the one or more prepaid cards, the 

30 number of times the card has been used. 

13 . The system of claim 1 wherein the database further 
stores, for each of the one or more prepaid cards, a 
bonus point total derived from the use of the card and a 

35 redeemed point total indicating then number of bonus 

points that have been redeemed. 
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The system of claim 13 wherein the bonus point total is 
the total dollar amount of transactions in which the 
card was used to purchase goods and services. 

A method of processing prepaid card transactions 
comprising the steps of: 

a. reading a prepaid card, including identifying 
information, at an activation terminal; 

b. entering at the activation terminal a value to be 
added to the prepaid card; 

c. sending to a host computer (i) information 
identifying the prepaid card, (ii) the value to be 
added to the prepaid card, and (iii) identification 
information associated with a person operating the 
activation terminal; 

d. determining whether the person operating the 
activation terminal is authorized to operate the 
activation terminal and, if the person is 
authorized, adding the value to a balance stored in 
a database entry associated with the prepaid card; 

e. reading the prepaid card, including identifying 
information, at a clerk terminal; 

f . entering at the clerk terminal a value to be 
redeemed from the prepaid card; 

g. sending to the host computer (i) information 
identifying the prepaid card, (ii) the value to be 
redeemed from the prepaid card,, and (iii) 
identification information associated with a person 
operating the clerk terminal; 

h. subtracting the value to be redeemed from the 
prepaid card from the balance stored in the 
database entry associated with the prepaid card if 
(i) the person operating the clerk terminal is 
authorized to operate the clerk terminal and (ii) 
the balance in the database entry associated with 
the prepaid card is greater than or equal to the 
value to be redeemed. 
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The method of claim 15 further comprising the steps of: 

a . reading at a manager terminal a manager card 
identification number from a manager card; 

b. entering at the manager terminal a manager terminal 
operation; 

c. entering at the manager terminal identification 
information associated with a person; 

d. sending to the host computer the manager card 
identification number, the operation and the 
identification information associated with the 
person ; and 

e. determining whether the manager card identification 
number is from an authorized manager card and, if 
so, updating information in the database, based on 
the entered operation, regarding whether the person 
having the entered identification information is 
authorized to use certain activation, clerk and 
manager terminals . 

The method of claim 16 where the operation is to 
authorize the person having the entered identification 
information to use certain activation, clerk and manager 
terminals. 

The method of claim 16 where the operation is to remove 
authorization of the person having the entered 
identification information to use certain activation, 
clerk and manager terminals. 

The method of claim 16 where the certain activation, 
clerk and manager terminals are all activation, clerk 
and manager terminals in the same store as the manager 
terminal sending information to the host computer. 

A method of processing prepaid card transactions 
comprising the steps of : 
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connecting a workstation to a host computer wherein 
the host computer can access a database storing 
information regarding prepaid cards and terminals 
for performing prepaid card transactions; 
determining access rights of a user at the 
workstation to the information in the database, 
including 

(1) whether the user may increase a current 
balance associated with one of the prepaid 
cards ; 

(2) an amount the user may add to the current 
balance associated with one of the prepaid 
cards in a single transaction; and 

(3) a total amount the user may add to the current 
balance associated with one of the prepaid 
cards over a specified period of time. 



21. The method of claim 15 further comprising the step of 
sending terminal identification information to the host 

20 computer and wherein the steps of determining whether 

the persons operating the activation and clerk terminals 
are authorized comprises, for each such person, locating 
a database entry associated with the received terminal, 
the database entry specifying a list of persons 

25 authorized to use the terminal, and determining whether 

the person operating the terminal is on the list of the 
authorized persons. 

22. The method of claim 15 wherein the steps of adding the 
30 value to the balance and subtracting the value to be 

redeemed from the balance further comprise, for each 
transaction, storing transaction information comprising: 
a. information identifying the terminal at which the 

transaction was initiated, 
35 b. information identifying the person operating the 

terminal ; 
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c. information identifying the prepaid card whose 
balance was modified; 

d. an amount of the transaction; and 

e. a type of the transaction. 

The method of claim 15 further comprising the steps of 

a. determining a list of sales representatives 
entitled to commissions for transactions occurring 
at the activation and clerk terminals, 

b. determining commissions owed to the sales 
representatives on the list of sales 
representatives and to an operator of the host 
computer, and 

c. paying the commissions from a specified account 
associated with the terminals. 

The method of claim 23 further comprising the step of 
storing, for each transaction for which a commission is 
owed, information regarding whether the commission has 
been paid from the account. 

The method of claim 15 further comprising storing in the 
database entry associated with the prepaid card the 
number of times the card has been used. 

The method of claim 15 further comprising storing in the 
database entry associated with the prepaid card a bonus 
point total derived from the use of the caYd and a 
redeemed point total indicating the number of bonus 
points that have been redeemed. 

The system of claim 26 wherein the bonus point total is 
the total dollar amount of transactions in which the 
card was used to purchase goods and services. 
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The system of claim 1 wherein a set of the one or more 
prepaid cards is for prepaying for a service billed on a 
periodic basis. 

The system of claim 1 wherein a set of the one or more 
prepaid cards is for prepaying for prepaid local 
telephone service. 

A prepaid card system for prepaying for a service billed 
on a periodic basis comprising: 

a. one or more prepaid cards each having an associated 
account number; 

b. at least one activation terminal at which value can 
be added to the one or more prepaid cards; 

c. a computer associated with a provider of the 
service; 

d. a host computer that can communicate with the at 
least one activation terminal and the provider 
computer; and 

e. a database that can be accessed by the host 
computer wherein the database stores 

i) for each of the at least one activation 
terminals, information regarding each clerk 
authorized to use the terminal; 

ii) information regarding access rights of users 
of the provider computer to information in the 
database; and 

iii) for each of the one or more prepaid cards, a 
current balance associated with the prepaid 
card and information regarding the prepaid 
service . 

The system of claim 30 wherein the prepaid service is 
prepaid local phone service. 
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32. A method for processing prepaid transactions for a 
service billed on a periodic basis comprising the steps 
of; 

a. reading a prepaid card, including identifying 
1 information, at an activation terminal; 

b. entering at the activation terminal a value; 

c. entering at the terminal a product code; 

d. sending to a host computer (i) the card identifying 
information, (ii) the value, (iii) the product 
code, and (iv) identification information 
associated with a person operating the activation 
terminal ; and 

e. at the host computer, 

(1) determining whether the person operating the 
activation terminal is authorized to operate 
the activation terminal; 

(2) if the person operating the terminal is 
authorized, locating a database entry 
associated with the prepaid card, the database 
entry storing a balance; 

(3) determining a price associated with the 
product code, and 

(4) determining whether the received value plus 
the balance is greater than or equal to the 
price and, if it is, adding the value to the 
balance in the database entry and storing 
information regarding the product code in the 
database entry. 

33. The method of claim 32 further comprising the step of: 

sending to a computer associated with a provider of 
the service the card balance and the information 
regarding the product code and setting the card 
balance in the database entry to zero. 

34. The method of claim 33 further comprising the steps of: 
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a. determining at the provider computer a price 
associated with the received product code 
information; and 

b. sending a message from the provider computer to the 

5 host computer instructing the host computer to 

credit the balance associated with the card if the 
price determined by the provider computer exceeds 
the balance received by the provider computer. 

10 35. The method of claim 32 wherein the product code 

specifies an initial activation of the service and 
further comprising the steps of: 

a. providing, by a customer to a representative of the 
provider, information regarding the card and 

15 customer information required for activating the 

service ; 

b. connecting a computer associated with the provider 
to the host computer and determining whether the 
representative is authorized to access information 

20 regarding the card; and 

c. if the representative is authorized, sending to the 
provider computer the card balance and the 
information regarding the product code. 

25 36. The method of claim 32 wherein the service is prepaid 
local phone service. 
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